This one is not so important now, we must first discuss three above, but we can
start it too.

I think code of libraries should be unique and kept simple. Here are my suggestions:

- Keep it raw (like FASM's sources). Use macros only when they really have
  effort on readability of code.

- lowcase instructions 

? use tabs (?)
   mov ax, bx <spaces> ;comment 
   mov ax, bx <tabs> ;comment 
   mov <tab> ax,bx <tab> ;comment 
   mov <spaces> ax,bx <spaces> ;comment 
   <tab> mov <tab> ax,bx <tab> ;comment 
   <spaces> mov <spaces> ax,bx <spaces> ;comment

? Coding style in "code blocks". This is how people should code in assembly,
  not structured code but "linear", divided into blocks where each block
  performs simple tasks. Look at Fresh and FASM's sources and it seems all
  big assembly projects are coded this way. Maybe we could make this style
  a rule.

- Based on previous, commenting: comment before block of code what it does.
  comments on right side of line with instruction only refer to unclear 
  details of instruction, like description of numeric constant etc. 

- All comments on right side in block should be aligned. 

- Different blocks of comments can have different alignation (some blocks can
  contain very long instruction which forces moving comments too far to the
  right, and such block shouldn't affect others)

? Right-side comments won't be wrapped. Comments of block will be wrapped. 

? Instructions and data definition will be wrapped
  
? Commenting data declaration

? I'd like to agree on using 0*h format of hexadecimal format. It is most
  "assembly" ("$*" is taken from pascal and "0x*" from C), and it would
  be nice and prevents some confusion to have standard in this too.

- formatting of arguments:
   mov ax,[ds:2*esi+edi+2]
   mov ax, [ds:2*esi+edi+2]
   mov ax, [ds:2*esi + edi + 2]
   mov ax, [ds: 2*esi + edi + 2]
   etc.
  is left on coder, insert spaces to reflect hierarchies

? Screen 80 characters wide, except things which aren't wrapped.
